Telecommunication services reporting system

ABSTRACT

A system and method of providing telecommunication services reports is disclosed. In a particular embodiment, the method includes receiving a plurality of call detail records (CDRs) from a server. The plurality of CDRs are associated with a particular telecommunications service provider and each of the plurality of CDRs includes a data structure that includes one or more fields, one or more subfields, or any combination thereof. The method also includes generating a report based on data within at least one of the one or more fields, at least one of the one or more subfields, or any combination thereof, of the plurality of CDRs.

CLAIM OF PRIORITY

The present application is a continuation application of and claimspriority to U.S. patent application Ser. No. 11/405,986 filed on Apr.18, 2006, which is a continuation application of and claims priority toU.S. patent application Ser. No. 10/024,847 filed on Dec. 19, 2001. Thecontents of U.S. patent application Ser. No. 11/405,986 and U.S. patentapplication Ser. No. 10/024,847 are expressly incorporated herein byreference in their entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates to telecommunication networks, and inparticular, to systems and methods for providing telecommunicationsservices reports.

BACKGROUND

The deregulation of the telecommunications industry has resulted in anenvironment where subscribers are given many choices oftelecommunications service providers. Each service provider typicallyoffers different rate plans that govern the cost the subscriber pays forvarious voice and data transmissions. In addition, the network overwhich the telecommunication services are provided, may be only partiallyowned or leased by the subscriber's particular service provider. To keeptrack of subscriber billing or network usage and communication services,service providers rely upon records created for each subscribertransaction on the network. For example, a call detail record (CDR) isgenerated when a telephone call is placed by a subscriber across thenetwork. Groups of CDRs are stored in files of various formats and sizesfor periodic retrieval and processing by a computer-based billingsystem.

For example, a CDR is created when a subscriber uses a calling card toplace a telephone call. An example of a platform for processing suchcalling card accounts is the InterVoice Brite system used by SBCTelecommunications. The calling card system creates CDRs which areavailable for downstream processing systems to provide billing fornetwork time or create customer billing records for network usage orgenerate network usage reports for the service provider. In a typicalbusy hour such systems can create files containing more than 5,000 CDRs.Currently, the available reporting functions from the calling cardplatform are limited. Accordingly, there exists a need for an improvedreporting system to manage customer accounts and provide networkauditing and statistical measures for service provider analysis andbusiness planning.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is pointed out with particularity in the appended claims.However, other features of the invention will become apparent and theinvention will be best understood by referring to the detaileddescription in conjunction with the accompanying drawings in which:

FIG. 1 is a schematic block diagram of a telecommunication system inwhich the present invention may be used to advantage.

FIG. 2 is a schematic block diagram of a carrier identification codereport generated by the reporting system of FIG. 1.

FIG. 3 is a logic flow diagram of one method of processing call detailrecords in accordance with the present invention.

FIG. 4 is a logic flow diagram of another method of processing CDRs inaccordance with the present invention.

FIG. 5 shows one example of a report generated in accordance with themethod of FIG. 4.

DETAILED DESCRIPTION

The various embodiments of the present invention are advantageous forreporting on system usage. In one embodiment, a system to providetelecommunication services reports is disclosed that includes processinglogic and memory accessible to the processing logic. The memory includesinstructions executable by the processing logic to receive data relatedto a plurality of call detail records (CDRs) from a server. Theplurality of CDRs are associated with a particular telecommunicationsservice provider and each of the plurality of CDRs includes a datastructure that includes one or more fields, one or more subfields, orany combination thereof. The memory also includes instructionsexecutable by the processing logic to generate a report based on datawithin at least one of the one or more fields, at least one of the oneor more subfields, or any combination thereof, of the plurality of CDRs.

In another embodiment, a method of providing telecommunication servicesreports is disclosed that includes receiving a plurality of call detailrecords (CDRs) from a server. The plurality of CDRs are associated witha particular telecommunications service provider and each of theplurality of CDRs includes a data structure that includes one or morefields, one or more subfields, or any combination thereof. The methodalso includes generating a report based on data within at least one ofthe one or more fields, at least one of the one or more subfields, orany combination thereof, of the plurality of CDRs. 10013] In anotherembodiment, a method of providing telecommunication services reports isdisclosed that includes receiving information related to atelecommunication service of a plurality of telecommunication servicesat a system cluster of a plurality of system clusters from atelecommunications network. Each system cluster is associated with arespective telecommunication service. The method also includesgenerating a plurality of call detail records (CDRs) based on theinformation received from the telecommunications network. In addition,the method includes sending the plurality of CDRs from the systemcluster to a CDR service splitter. Further, the method includesreceiving a first set of CDRs and a second set of CDRs at the systemcluster from the CDR service splitter, where the first set of CDRs isassociated with a first telecommunications service provider and thesecond set of CDRs is associated with a second telecommunicationsservice provider.

In the following examples, the method and system are described withrespect to a long distance calling card platform and the CDRs generatedthereby. This is but one example, of many, in which the presentinvention may be advantageously used. Such other systems arecontemplated by the present invention.

Referring now to FIG. 1, there is shown a schematic block diagram of atelecommunication system in which the present invention may be used toadvantage. In FIG. 1, a telecommunications network 10 representing, forexample, the public switched telephone network (PSTN) is disclosed whichprovides telecommunication services to a plurality of networksubscribers 12 having a respective customer premises equipment. Thetelecommunications network 10 provides a variety of voice and dataservices for each of the subscribers 12 or groups of subscribers. Forexample, the telecommunications network 10 can provide plain oldtelephone service (POTS) as well as enhanced services such as callwaiting, caller identification, call forwarding, three-way conferencing,etc. In the example shown in FIG. 1, telecommunications network 10provides calling card functionality as part of its enhanced networkservices. Accordingly, telephone calls placed by way of calling cardsare processed by a calling card system cluster, one of which isrepresented by controller 14. However, the calling card network portionof telecommunications network 10 may include multiple clusters 14 whichare linked to a master database 16 and kept current using a replicateddatabase 18 by methods known to those of skill in the art. In oneexample, several clusters 14 are included, one for servicing each regionof the telecommunication network where calling card service isavailable.

One example of a calling card system cluster 14 is the long distancecalling card platform available from InterVoice Brite Corporationimplemented in the SBC telecom network. The calling card system cluster14 is coupled to the telecommunications network 10 and generatestransaction records (CDRs) including transaction data corresponding toat least one telephone call placed by at least one subscriber 12. Thecluster 14 generates transaction records in a manner that is known tothose of skill in the art. The cluster 14, as described in more detailbelow, works with downstream processing systems to process the CDRs toprovide billing statements or network usage reports for at least one ofa plurality of subscribers or service providers. In the case of thecalling card system cluster 14, the first analysis point for eachtransaction record downstream of the cluster 14 is a system known as theCDR service splitter 20. The splitter 20 divides the CDRs, typically byservice provider or network vendor, and further forwards each recordeither directly, or through the cluster 14, to appropriate subsystemsfor further processing.

After the CDRs have been preprocessed by the splitter system 20,selected CDRs are retrieved from each cluster 14 by a productiondatabase server 22 by way of a streaming socket or other knowncommunications link, and posted to a CDR table. Significant data fromthe CDR tables can be subsequently summarized and stored in a roll-uptable within the production database server 22.

The production database server 22 is accessed by a production web server24 which is a computer implemented system running application softwareto generate billing statements or reports regarding network usagecorresponding to at least one telephone call. The reporting systemapplication software resides on the production web server 24 and allowsa user to access the information within the roll-up tables stored in theproduction database server 22. Access to the production web server 24can be by way of a corporate intranet 26 in cooperation with a useraccess terminal 28 such as a personal computer. In this way, user accessto the reporting system application software is made through thecorporate intranet website, and compiled reports are queried anddelivered from the production web server 24 to the user terminal 28 byway of the intranet 26. Of course, alternative access to the productiondatabase server and the corresponding CDR files could be implementedsuch as by a direct connection between the user terminal 28 andproduction database server 22 with the reporting system applicationsoftware resided directly on the user terminal 28. Other locations forthe reporting system application software are also contemplated by thepresent invention such as within the calling card system cluster 14, orCDR server splitter 20. In the example shown in FIG. 1, however, theCDRs generated by the calling card system cluster are processed off thecluster network 14 or splitter network 20 on a stand-alone system in theform of production database server 22 and production web server 24.Similarly, although access to production web server 24 is shown as beingthrough intranet 26 by way of a user terminal 28, access could also beprovided through a secure internet by methods known to those of skill inthe art.

In operation, for each transaction on the telecommunications network 10,a record in the form of a call detailed record is created. For each typeof service provided by the telecommunications network 10, a separateprocessing system may exist. In this example, the service of concern iscalling card services and the system which processes all calling cardtransactions is the cluster 14 or multiple clusters 14. Cluster 14 mayalso process other enhanced network services such as AutomatedAttendant, or the enhanced network services may be processed by theirown corresponding subsystem of the telecommunications network 10. In anyevent, for purposes of illustration herein, each calling cardtransaction on the telecommunications network 10 generates a CDR bycluster 14.

Each CDR generated by the cluster 14 may be defined as a data characterstring such as, for example, a 385 character line terminated by a linefeed wherein different portions of the character string represent dataassociated with the call detail record. For example, characters 22through 32 of the character string may represent a directory numberinbound service number. Other portions of character string may indicatethe billing number, the billable time, the automatic numberidentification, the rate class, the inbound and outbound trunk numbers,the date and time, and so on. The CDRs generated by the cluster 14 areperiodically transmitted to the CDR server splitter 20 for storage anddistribution. Similarly, the production database server 22 isperiodically updated, such as hourly, with the CDRs generated by thecluster 14 and processed by the CDR server splitter 20.

The calling card CDRs are collected in real time from each of thecalling card system clusters 14. This data is posted to the productiondatabase server 22 which retains a history of CDRs such as, for example60 days of CDRs. The CDR roll-up table is periodically generated such asonce a day. For example, the roll-up routine will read the previousday's usage from the production database server CDRs and accumulatespecific significant data and store the same in the form of roll-uprecords. A roll-up table stores the roll-up records sorted by date andservice provider.

Referring now to FIG. 2 there is shown a schematic block diagram of acarrier identification code (CIC) report generated by the reportingsystem of FIG. 1. Each transaction record in the form of a CDR isrepresented by a number of fields containing information about atelephone call. Thus, an originating number field comprises a ten digitnumber identifying the calling party and a terminating number fieldcomprises a ten digit number identifying the called party. A connectdate field indicates the date that the transaction was made. A connecttime field indicates the time of day the connection was made, and aduration field specifies the length of the call. A transactionidentifier is also included to uniquely identify the CDR from all otherCDRs processed by the system. From the 385 character data linerepresenting an individual CDR, the CIC report of FIG. 2 is generated.The report 30 includes a header 32 having a plurality of fields 34 eachof which may include one or more subfields 36. As an initial matter, theCIC reports 30 are associated with each particular carrier registeredwith the telecommunications network. Thus, the first grouping or sortingof CDRs generated by the cluster occurs at the carrier identificationlevel. In this example, the CIC information is located in positions187-190 and is four characters in length within the CDR. Having sortedthe CDRs by the carrier identification code, each group of CDRsassociated with a respective carrier is then compiled in the form of thereport 30 of FIG. 2.

The report 30 is generated at the direction of the user at the userterminal 28 or it may be automatically periodically generated at theproduction web server 24 and stored. The type of report, the sortingfields, and the layout of the presentation can all be readily selectedat the user terminal 28. In this way, the reporting functions of thepresent invention provide significant advantages and flexibility.

The fields 34 within the header 32 of the report 30 can include a Datefield, Call Type Offered field, System Failure field, Rate Class field,Method of Recording field and Message Type field. The fields 34 andsubfields 36 represented in record 30 may be advantageously compiled aspart of the daily CDR roll-up procedure within the production databaseserver 22 during retrieval and analysis of CDR records from each CDRcluster 14.

The Date field is used to sort the records by date for presentationwithin a periodic report such as, for example, a monthly, quarterly oryearly report. For the InterVoice Brite network cluster in the exampleof the present invention, the date information is located in positions7-14 and is eight characters in length within the CDR.

The Call Types Offered field indicates the total daily counts for, inthis case, all calling card calls. Several subgroups are identifiedwithin the Call Types Offered field for distinguishing between thevarious types of calling card transactions recorded by the system. Thus,it is indicated whether a Local Exchange Carrier (LEC) or Proprietarycalling card had been used in originating the calling card call. The LECand Proprietary card data is located in positions 199-200 and is twocharacters in length within the CDR. Reorigination or sequence countdata is also recorded as a subgroup within the Call Types Offered fieldand is located in positions 262-263 and is two characters in lengthwithin the CDR. Reorigination/Sequence Calls are subsequent calls madeduring a single access to the platform. For example, when a subscriberplaces an initial call using standard procedures, once the call ends thesubscriber has the option to generate a second call by pressing the #key on their phone. This eliminates the need for the caller to re-dialthe 8XX access number to place a second call.

The Systems Failure field indicates the call time duration as well asincomplete call information. The time on the platform data is located inthe Voice Response Unit (VRU) time data fields located at positions246-251 and is six characters in length within the CDR. In one aspect ofthe invention, the data within the VRU time subfield is totaled andaveraged for reporting purposes. The Incomplete Call informationsubfield is located within the indicator 18 field of the CDR at position106 and is one character in length.

The Rate Class field maintains the types of call processed by thenetwork. The Rate Class information is located in position 85 and is onecharacter in length within the CDR. In the example of FIG. 2, fivepossible rate classes are shown and in one embodiment can be sortedaccording to each CIC and totaled for the date of interest. Twodifferent subfields within a Rate Class are: Person-to-Person (PSN toPSN), Operator Station-to-Station, Dialed Station, Operator Assistedtrouble assist, and Auto.

The Method of Recording field indicates the level of automation used andoperator involvement for calls presented to the platform. The Method ofRecording data is located in position 74-75 and is two characters inlength. Advantageously, each column for the four possible methods ofrecording are sorted by CIC and totaled for the particular date(s) ofinterest. The four Methods of Recording are identified by option numberswithin the two-character field wherein Option 1 represents a customerdialed station with no operator assistance, Option 3 represents acustomer dialed transaction which was automatically dialed, Option 11represents a customer dialed transaction with operator assistance, andOption 13 represents an operator completed transaction.

The Message Type field records the type of call processed by thecluster. The Message Type data is located in position 86 and is fourcharacters in length within the CDR. The subfields associated with theMessage Type fields are Sent Paid, Third Number Billing, Calling Card,or Collect Call. The Call Statistics field identifies any enhancedservices which are used during the call transaction. Examples ofsubfields within the Call Statistics field are identified as MessageStore and Forward (MSF), Directory Assistance (DA), and Conference Call(CFC). Additional enhanced services are also contemplated for reportingservices by the present invention.

For each CIC, the periodic CIC report includes a plurality of CDRentries 38. The plurality of CDRs represented by the table or report 30can advantageously be further processed such as, for example, byproviding a Total of any one or more of the data fields 34 or subfields36 represented in the report 30 such as shown in the footer Total 40.Averages, minimums and maximums may also be provided.

Referring now to FIG. 3 there is shown a logic flow diagram of onemethod of processing call detail records in accordance with the presentinvention. The logic resides in the production web server 24 and isaccessed through the intranet connection 26 by the user terminal 28. Themethod begins in step 50 by periodically acquiring CDRs from the callingcard system cluster 14 (FIG. 1). For example, each day the CDRsgenerated by the cluster can be processed. In step 52, the CDRs aresorted by carrier identification code (CIC) such that carrier-specificreports can be generated. The CDRs associated with a particular carrierare then date sorted in step 54. In step 56, the Call Types Offeredfield is determined by querying the CDR data string as explained abovewith reference to FIG. 2. Similarly, in steps 58-66, the remainingfields 34 and subfields 36 of the periodic CIC report 30 of FIG. 2 aredetermined as explained above. Thus, the system performance andstatistics are generated in step 58, the Rate Class is determined instep 60, the Method of Recording is determined in step 62, the MessageType is determined in step 64, and Call Statistics relating to enhancedservices are determined in step 66.

Based upon the data fields analyzed for each CDR, a variety of reportscan be generated in step 68. Thus, for example, the periodic CIC report30 of FIG. 2 can be readily compiled in a format as shown which simplyreplicates the information within each of the determined fields andsubfields. Several customized reporting functions are contemplatedhowever by the present invention. These include a System Performancereport, an Operator Assistance report and a Call Statistics report.

The System Performance report is a further refinement of the periodicCIC report 30 of FIG. 2 and includes only those fields relating tonetwork performance statistics. Advantageously, the System Performancereport includes the VRU Time subfield and Incomplete Message Store andForward (MSF) which is represented by the Indicator 18 subfield. TheSystem Performance report is intended to assist network operations andengineering personnel in understanding the daily activity occurringwithin each active calling card system cluster wherein the clusterrepresents a plurality of calling card network servers at a specificlocation, i.e., a city. The database servers associated with a callingcard system cluster such as replicated database 18, master database 16and production database server 22 of FIG. 1, can be remotely locatedfrom the calling card system cluster. In its simplest form, the SystemPerformance report as identified above defines the daily statisticscaptured within each calling card cluster and presents them in a formatunderstandable by a user interested in such statistics.

As a further example, an Operator Assistance report can be generated.This report groups and presents those subfields associated with operatoractivities for presentation to a user. Thus, the subfields identified asOperator Station-to-Station calls, Operator Trouble Assists, OperatorAssisted Customer Dialing, and Operator Completed Dialing betweenparties data is represented in the Operator Assistance report. TheOperator Assistance report can be advantageous in analysis and planningof staffing and customer service.

A Call Statistics report is also contemplated which includes all of thesubfields within the Call Statistics field of the periodic CIC report.Thus, data regarding usage of enhanced services such as Message Storeand Forward, Directory Assistance, and Conference Calling can beanalyzed and reported. Advantageously, marketing personnel can utilizesuch a report to measure market penetration for enhanced services. Suchmarketing data can be sorted by CIC as well as geographically.

A Call Origination Report is also contemplated. The report analyzes theCDRs by originating state and country and further sorts the CDRs by CICand date. In this way, statistical analysis of network usage can beconducted. The originating trunk report described below can provide theinformation of the Call Origination Report.

Referring now to FIG. 4 there is shown a logic flow diagram of anothermethod of generating a report from CDRs in accordance with the presentinvention. FIG. 4 describes one method of generating a trunk capacityreport which displays, on a periodic basis, the total number of incomingand outgoing call attempts associated with each unique trunk groupcorresponding to the switching network. The data used to generate thetrunk capacity report is again available from the calling card networkCDRs generated by the calling card system clusters. Referring now toFIG. 4, in step 80 the logic routine determines the origination sectionor cluster. Identification of the individual clusters is accomplished bysorting the individual cluster identifications as defined in the callingcard CDR character string. This data is located in CDR field 86 and istwo characters in length. The cluster id's are defined to identify thephysical location of each of the clusters within the system. Thus, forexample, cluster identification number 01 may refer to the clusterlocated in Houston, whereas cluster identification number 02 may referto the cluster located in Anaheim.

In step 82, the logic routine continues with identification of theOriginating Trunk Group within a cluster by sorting the calling cardCDRs using the originating trunk group number. This data is located infield 87 of the CDR character string and is three characters in length.Again, a look-up table of values can be indexed by the three characteroriginating trunk group number to identify the switching networklocation associated therewith.

The logic routine continues in step 84 by determining the Total MembersAvailable from each network switch origination point. This isaccomplished by multiplying the total number of T-1 lines incoming tothe switch by 24 to determine the total number of available members. Thenumber of T-1s available at the switch can be determined from a look-uptable of values indexed by the originating trunk group number as in step82.

The logic routine then continues in step 86 to determine the Total CallAttempts again using the originating trunk group information from CDRfield 87 as determined from step 82. To determine the total callattempts, the CDRs are first sorted by originating trunk number and thensorted using the look-up table (i.e. conversion chart) to sort theinformation according to originating switch. The total number of recordsreceived for the day within each group is then added to the specificcluster site to determine the total number of incoming (originating)call attempts from each network switch.

Once the number of Total Call Attempts has been determined, the numberof Successful Call Attempts is determined in step 88. This isaccomplished by sorting the information just gathered in thedetermination of the Total Call Attempts by the CDR data field 41 whichcorresponds to “Indicator 18” which is set if a call was incomplete.Thus, all CDR records that have a value of zero within this CDR fieldare considered successful and/or completed telephone calls. The totalfor all CDRs associated with each originating trunk group having a valueof zero within this CDR field corresponds to the number of successfulcall attempts for the respective originating trunk group. The number ofincomplete call attempts in step 90 is similarly determined by analysisof the “Indicator 18” field within the CDR character string. All CDRrecords having a value of, for example, two in the Indicator 18 fieldare considered an incomplete call. The total number of records havingthis value for each originating trunk group are then totaled todetermine the total number of incomplete call attempts for theassociated originating trunk group.

The VRU Time is next determined in step 92 by using the results from theTotal Call Attempts calculation and totaling the time recorded withineach CDR record field corresponding to VRU Time to determine the totalnumber of VRU seconds for the associated originating trunk group. Thistotal can either be recorded and/or the total VRU Time can be divided bythe number of CDR records associated therewith in the total attemptscalculation to determine the average VRU Time in seconds from eachoriginating trunk group.

Similar steps can be performed for the termination section to generate acorresponding terminating trunk group report similar to the originatingtrunk group data determined in steps 82-92. Thus, the terminating trunkgroup is identified within a cluster by sorting the calling card CDRsusing the terminating trunk group number located within field 89 of theCDR character string and being three characters in length. Thisidentification number can then be cross-referenced with a look-up tableof values indexed by the identification number to determine thecorresponding terminating trunk number and switching network location.To determine the Total Members Available for the termination section, asimilar calculation to that set forth with respect to step 84 isperformed. The Total Call Attempts for the termination section uses theoriginating trunk group information and sorts the CDRs by originatingtrunk number. The originating trunk number is then used to identify theoriginating switch from the look-up table of values indexed byoriginating trunk number. The total number of records received for theday within each group to the specific cluster site is then added todetermine the total number of incoming (originating) call attempts fromeach network switch. The CDR fields corresponding to “Record Type” aswell as the CDR fields corresponding to “Rate Class” are then analyzed.If the Record Type field is something other than “01,” it is totaled.Similarly, if the Rate Class field has a value of something other than“06,” it is totaled. Values recorded in these fields are indicative ofterminated calls. Thus, the two total counts derived from theirrespective fields is indicative of the actual terminating count totalfor each outgoing (terminating) call attempt to each network switch. Thesteps necessary to determine the number of Successful Call Attempts,Incomplete Call Attempts, and VRU Time (either average or total) aresimilar to those set for with respect to steps 88-92 above.

In step 94, the report is compiled periodically, such as daily, for eachcalling card system cluster. The report can advantageously be dividedinto originating trunk group information and terminated trunk groupinformation based upon the foregoing method.

Referring now to FIG. 5 there is shown one example of a report generatedin accordance with the method of FIG. 4. In FIG. 5, the report 100relates to one of the plurality of clusters within the network. In thiscase, the Houston cluster is identified. Further, the report can beeither compiled for the identified cluster on a daily, monthly,quarterly, yearly or other periodic basis. The report 100 is split intosections corresponding to the originating trunk group information 102and terminated trunk group information 104 for the cluster of interest.Separate line items are generated for each originating and terminatingswitch connection to the respective cluster. The report of FIG. 5, andall reports generated by the system, can be displayed on the userterminal 28, saved in any of the servers, or printed.

The foregoing reporting method and enhanced services network system hasseveral advantages. The reporting system and method has the ability toidentify and sort call attempts made into the platform by customer CIC.All information corresponding to a particular CIC is available forsorting and displaying in a periodic format such as daily or monthly.Numerous individual statistics are also available such as the totalnumber of local exchange carrier (LEC) calling card attempts on aperiodic basis, the number of proprietary calling card attempts, thenumber of reorigination attempts, either LEC or proprietary, the numberof invalid call attempts, as well as the use and/or market penetrationof any enhanced service features such as Method Store and Forward,Directory Assistance or Conference Calling. The system also has theability to identify by CIC, the number of calls transferred to operatorassistance. Moreover, the user interface is advantageously implementedthrough a secure internet or intranet based server system. As a resultof the flexibility and usability of the data analysis available from thesystem, the system can be used to advantage many users. Carriers haveaccess to usage data and can be provided with customized billingrecords, marketing personnel can utilize the reports featured to measuremarket penetration of platform features and call origination volumes bycarriers, network operations personnel can use the reporting featuresfor auditing customer call flows, tracking platform hold time, andassisting with network maintenance, network engineering personnel canuse the reporting features to determine actual call volumes versusforecasted call volumes and for managing equipment platform capacity,and the reporting features can also be used to staff telecommunicationsfacilities based upon patterns of operator assistance. Numerous otherreporting functions will present themselves to those of skill in the artin view of the foregoing disclosure and, indeed, are contemplated by thepresent invention.

From the foregoing, it can be seen that there has been brought to theart a new and improved system and method for processing call detailrecord files. Although the invention has been described in connectionwith one or more embodiments, it should be understood that the inventionis not limited to those embodiments. On the contrary, the inventioncovers all alternatives, modifications and equivalents as may beincluded within the spirit and scope of the appended claims.

1. A method of providing telecommunication services reports, the methodcomprising: receiving a plurality of call detail records (CDRs) from aserver, wherein the plurality of CDRs are associated with a particulartelecommunications service provider and wherein each of the plurality ofCDRs includes a data structure that includes one or more fields, one ormore subfields, or any combination thereof; and generating a reportbased on data within at least one of the one or more fields, at leastone of the one or more subfields, or any combination thereof, of theplurality of CDRs.
 2. The method of claim 1, wherein the one or morefields includes a carrier identification field and at least oneadditional field and wherein the report is generated based on the atleast one additional field.
 3. The method of claim 1, furthercomprising, receiving a request to generate the report from a userterminal via an intranet, an internet, or any combination thereof. 4.The method of claim 3, wherein the at least one of the one or morefields, the at least one of the one or more subfields, or anycombination thereof, is user-selected.
 5. The method of claim 3, furthercomprising, sending the report to the user terminal.
 6. The method ofclaim 1, wherein the report is generated automatically.
 7. The method ofclaim 6, wherein the report is generated periodically.
 8. The method ofclaim 1, wherein the server includes a CDR service splitter, a systemcluster, a production database server, or any combination thereof.
 9. Amethod of providing telecommunication services reports, the methodcomprising: receiving information related to a telecommunication serviceof a plurality of telecommunication services at a system cluster of aplurality of system clusters from a telecommunications network, whereineach system cluster is associated with a respective telecommunicationservice; generating a plurality of call detail records (CDRs) based onthe information received from the telecommunications network; sendingthe plurality of CDRs from the system cluster to a CDR service splitter;and receiving a first set of CDRs and a second set of CDRs at the systemcluster from the CDR service splitter, wherein the first set of CDRs isassociated with a first telecommunications service provider and thesecond set of CDRs is associated with a second telecommunicationsservice provider.
 10. The method of claim 9, wherein the respectivetelecommunication service is a calling card service.
 11. The method ofclaim 9, further comprising, generating a first report based on dataincluded in the first set of CDRs and generating a second report basedon data included in the second set of CDRs.
 12. The method of claim 11,further comprising, sending the first report and the second report to auser terminal.
 13. A system to provide telecommunication servicesreports, the system comprising: processing logic and memory accessibleto the processing logic, the memory including: instructions executableby the processing logic to receive data related to a plurality of calldetail records (CDRs) from a server, wherein the plurality of CDRs areassociated with a particular telecommunications service provider andwherein each of the plurality of CDRs includes a data structure thatincludes one or more fields, one or more subfields, or any combinationthereof; and instructions executable by the processing logic to generatea report based on data within at least one of the one or more fields, atleast one of the one or more subfields, or any combination thereof, ofthe plurality of CDRs.
 14. The system of claim 13, wherein the calldetail records are received from a production database server via anintranet, an internet, or any combination thereof.
 15. The system ofclaim 13, wherein the report includes data from each of the one or morefields and from each of the one or more subfields.
 16. The system ofclaim 14, wherein the memory includes instructions executable by theprocessing logic to access roll-up tables in the production databaseserver.
 17. The system of claim 13, wherein the report includes datafrom a specified set of the one or more fields, the one or moresubfields, or any combination thereof, according to a type of thereport.
 18. The system of claim 17, wherein the type of the report isuser-selected.
 19. The system of claim 17, wherein the type of report isa system performance report, an operator assistance report, a callstatistics report, a call origination report, a trunk capacity report,or any combination thereof.
 20. The system of claim 19, wherein thetrunk capacity report is an originating trunk group report, aterminating trunk group report, or any combination thereof.